Seems like lld-link is once again discarding objc sections...

Making all for test_tool simpleTaskTests...
 Linking test_tool simpleTaskTests ...
lld-link: error: relocation against symbol in discarded section: __start_.objcrt$SEL
>>> referenced by ./obj/simpleTaskTests.obj/simpleTaskTests.m.o:(.objc_init)

lld-link: error: relocation against symbol in discarded section: __stop.objcrt$SEL
>>> referenced by ./obj/simpleTaskTests.obj/simpleTaskTests.m.o:(.objc_init)

lld-link: error: relocation against symbol in discarded section: __start_.objcrt$CLS
>>> referenced by ./obj/simpleTaskTests.obj/simpleTaskTests.m.o:(.objc_init)

lld-link: error: relocation against symbol in discarded section: __stop.objcrt$CLS
>>> referenced by ./obj/simpleTaskTests.obj/simpleTaskTests.m.o:(.objc_init)

lld-link: error: relocation against symbol in discarded section: __start_.objcrt$CLR
>>> referenced by ./obj/simpleTaskTests.obj/simpleTaskTests.m.o:(.objc_init)

lld-link: error: relocation against symbol in discarded section: __stop.objcrt$CLR
>>> referenced by ./obj/simpleTaskTests.obj/simpleTaskTests.m.o:(.objc_init)

@qmfrederik any idea why we're getting those linker errors now with MSVC and the MinGW errors?

@triplef The msvc job started failing when the NSURLSession rewrite (#422) PR got merged. This is the PR that introduced the simpleTaskTests and uploadTaskTests files which have the linker error.

The link failure may be related to llvm/llvm-project#49025. There's a workaround (see llvm/llvm-project#49025 (comment)) which probably works in this case, too?

It'd be a matter of adding this:

#if defined(__OBJC__) && defined(__clang__) && defined(_MSC_VER)
id __work_around_clang_bug = @"__unused__";
#endif

to simpleTaskTests.m and uploadTaskTests.m.

As a sidenote, I find that CI is most likely to be consistently green when all changes must go through pull requests, and CI is required to pass before a pull request can be merged. There's a fair amount of commits which have been pushed to the master branch without going through the PR process, and ended up breaking CI in one shape or form.

which probably works in this case, too?

Never worked for me, but I'll try :)

I don't understand why the linker discards the Objective-C sections. There should be enough Objective-C code in the unit tests... It builds with a newer version of lld-link too.

Edit: But this is only the case when GS_HAVE_NSURLSESSION is 1.

As a sidenote, I find that CI is most likely to be consistently green when all changes must go through pull requests, and CI is required to pass before a pull request can be merged. There's a fair amount of commits which have been pushed to the master branch without going through the PR process, and ended up breaking CI in one shape or form.

CI in #422 passed for all targets except MiNGW GCC which was broken at that time:
https://github.com/gnustep/libs-base/actions/runs/10177647029/job/28149581762

CI in #422 passed for all targets except MiNGW GCC which was broken at that time

That's odd. Perhaps something subtle changed in a new version of LLVM, which exposes this? It's a bit difficult to analyze CI failures in this project because CI often fails. I think it's easier to do root cause analysis of build failures in projects which consistently use CI and require builds to be CI.

which probably works in this case, too?
Never worked for me, but I'll try :)

Looks like it did work this time? 😄

Really happy to see CI gradually becoming greener, thanks!

Seems like we still have a deadlock in the NSThread test on MinGW GCC

Edit: But this is only the case when GS_HAVE_NSURLSESSION is 1.

Good catch. But should this not be the case for the MSVC CI?

But should this not be the case for the MSVC CI?

Yes but the CI decided it no longer wants to use libcurl ^^

checking for libcurl... FAILED (libcurl not found via pkg-config)

checking for libcurl... FAILED (libcurl not found via pkg-config)

I believe that libcurl is currently a 'soft' dependency, i.e. libs-base will just build without curl support if it didn't find it. Perhaps we should upgrade that to a 'hard' dependency, and forcing users to pass an explicit --without-curl flag if they don't want the curl support? That would cause CI to fail whenever it "forgets" to pick up curl.

(Sorry for the CI rants ^^)

Perhaps we should upgrade that to a 'hard' dependency, and forcing users to pass an explicit --without-curl flag if they don't want the curl support?

The only API that uses libcurl internally is NSURLSession which is only available when using the clang toolchain. Making it a hard dependency on GCC does not make sense. So perhaps a hard-dependency when using the libobjc2/clang toolchain?

Took some time to install the MinGW environment on poor ICE Wifi, but the culpit for the deadlock is the late_unregister.m NSThread test.

Everything except MinGW GCC works now. I cannot reproduce the deadlock and cannot get any logs out of the CI, as we use a test suite (a.k.a spaghetti shell code) that is unable to restrict the runtime of individual unit tests -_-

@qmfrederik can you take a look at late_unregister.m? It is randomly failing on MinGW.

I'd suggest turn the CI green first, and address the spurious failures in NSThread late_unregister.m and NSProxy separately, tracking it in an issue.

Otherwise, we continue merging PRs blindly without proper testing.